Client server model

ABSTRACT

A client-side intermediary ( 30 ) is provided to balance the loading of Web service requests between a plurality of servers ( 32 ). The status of the Web service servers ( 32 ) is monitored by a monitoring server ( 35 ) which provides status updates to the intermediary ( 30 ) upon request. The intermediary then uses the information on the status of the servers ( 32 ) to decide where to send web service requests. Additionally, the intermediary is able to direct requests for Web service descriptions to the least busy server on the basis of status information. The intermediary ( 30 ) substitutes its own identifier for the service name and port in the Web service description before passing it to the client so that all requests are directed through it, thus allowing the continual provision of service for the client even in the event that one of the servers fails.

This invention relates to an improved client server model, in particularto a system comprising a client module and several server modules, andto a method for managing service requests between the client and servermodules. The invention is particularly applicable in the area of highavailability Web services.

Web services are a form of distributed computing, in which one device (aclient) calls procedures provided on another device (server) so as touse the sevices provided by that server. There are a number of differentdistributed computing applications in which various different protocolsare used such as CORBA and DCOM. Distributed systems may use a varietyof different means for the client to call the procedure on the server,such as remote method in vocation (RMI), remote procedure calling (RPC)or message queuing.

Web services can be considered as a collection of functions which havebeen packaged together and published to a network for use by clientswithin the network. They provide the building blocks for creating opendistributed systems, and as such any number of Web services can becombined to form more complicated, higher level service. Today, Webservices are used to enable communication between computers in the formof messaging and RPC mechanisms across IP networks. Essentially, theadvantages of Web services over other distributed computing arrangementsare that they are particularly suited for heterogeneous environmentssuch as the internet. The reason for this is that the Web services usean XML-based communication protocol which is light weight and easilyunderstandable by all of the various different Web services. Inaddition, the Web services operate by transmitting communicationmessages using any underlying network communication protocols, but inparticular use HTTP which is ubiquitous throughout the internet. Theadvantages of Web services in the use of HTTP transport and XML encodingwhich are supported by many computing platforms such as Java andMicrosoft. One example of a Web service is Microsoft passport (anauthentication service hosted by Microsoft).

The protocol stack for Web services comprises, at the top, the Webservices applications which are offered by service providers for accessby a service requester (client). Under this, the XML-based communicationmechanism mentioned earlier is typically SOAP (Simple Object AccessProtocol)—this XML-based standard is a messaging framework designed forexchanging structured information in a distributed environment over avariety of underlying protocols, but is lightweight in that it missesout many advanced features such as reliability, security, and routing.The XML-bassed messaging protocol operates over the underlying networkcommunication protocols (eg HTTP). These features of Web services meanthat they provide one of the best interfaces for interoperabilitybetween legacy systems, Java and .Net systems. Unfortunately, they dosuffer from some limitations, in particular load balancing and loadsharing cannot be supported in the normal way.

Earlier British Telecommunications patent application PCT/GB02/03981 isdirected towards a system which overcomes some of the limitationsencountered in distributed computing. In particular, the system addressthe problems which can arise between a client-sever relationship whenone or more clients overuse the capabilities of the servers, and solvethese using the compulsory download of a client side intermediary whichacts to control the call rates allowed to the server. This therebyprevents the server from overuse by throttling back the call rate in theevent that the server becomes congested, and offering better loadcontrol of the services offered by the servers. However, this system isdirected towards a single client-sever relationship, and as such doesnot address the problems encountered in a multi-sever environment ofhigh availability Web services, in which duplicate Web services areoperated on several different servers. In particular, the failovercapability should one of the servers or Web services fail is notaddressed.

Whilst, in theory, re-routing to an alternative server in the event offailure can be performed in the system using known methods, these do notaddress the particular issues associated with Web service as outlinedbelow.

The provision of a Web service is summarised as follows: In order that aWeb service can be utilised, the Web service provider needs to makepublicly available details of the Web service applications, togetherwith the formats, protocols etc. necessary to access the service andcommunicate with the Web service server. This is achieved using a WSDL(Web Service Description Language) service description, which provides aspecification of the service, describing the location and interfacesused in Web services exchanges. The WSDL is downloaded by the client,which thereby has the information it requires in order to access theservice. Information provided by WSDL's includes services available,message formats and port numbers which should be used when accessingservices.

The client is able to decide which Web services are required, to createthe required XML-messages (using SOAP) which will invoke the Web serviceoperation from the Web service server. These messages are presentedtogether with the address of the service provider to a SOAP run timewhich interacts with an underlying network protocol (HTTP) to send aSOAP message over the network. The message is then delivered by thenetwork to the Web service SOAP server, where the XML message istranslated into the specific programming language relevant for theapplication. Finally, the Web service server produces a response in aform of a SOAP message which is sent back to the requesting client.

The particular problems with this procedure arise when the serverbecomes unavailable, since the “binding” which enables the client todirect the messages to the server is still in place, and the client willsuffer failed responses. The “binding” occurs as follows. The WSDLreceived by the client (which is used when generating the SOAP messagesfor accessing the Web service) additionally provides the service name(URI) and service port (URN). The URN and URI are combined together bythe client, to make a uniform resource locator (URL), i.e.:“http://www.ericaserver.bt.co.uk”+“/WebService1”=“http://www.ericaserver.bt.co.uk/WebService1”The client DNS (Domain Name Service) translates the URL into an IPaddress, and then the SOAP message is sent to the relevant destinationWeb service server, which is listening on the specific port for theincoming messages.

This procedure of “binding”, linking the WSDL to URL and then to IPaddress, is maintained thoughout the lifecycle of the client, unless theclient specifically demands a re-bind. In this case, all further callsto the service are performed without reference again to the WSDL. If theserver becomes congested or fails then the client only notices when ittries to send a SOAP message to the server and the process eventuallyfails. In this case, if the WSDL has multiple service names and portsspecified, then the client can attempt to rebind to another one.However, even if achieved this will have caused a disruption to theservice offered to the client. In addition, if the client has not beenprogrammed to cater for such a condition, then the client will fail. Inaddition to the problems encountered during failure of a server, nodistribution of loading is carried out since the client will only sendSOAP requests to one server (service port) unless the client is forcedto rebind before it sends every message. However, such dynamic rebindingwould require special programming by the client and in some cases theWeb services SDK (software development kit) supplied with .Net or Javamay not support It. In some cases, Web service bindings may last forlonger than the planned SOAP server uptime, thus when a server is takendown for maintenance the client will suffer failed responses.

Attempts to address this problem include a method known as the “DNSround robin method” in which multiple services IP addresses areregistered to the same DNS entry. However, this is flawed becausedynamic rebinding to the next IP address is not guaranteed. In addition,this method only works at the IP level, and not at the service name orport level.

The present invention seeks to mitigate the disadvantages of the priorart.

According to a first aspect of the present invention, there is provideda method of managing service requests from a first module acting as aclient module, to a plurality of other modules acting as server modules,the method comprising:

an information-collating module receiving from each of the other modulesan indication of the operational status of each of the other modules;

at the first module, a control intermediary receiving from theinformation-collating module an indication of the operational status ofeach of the other modules;

the control intermediary selecting one of the other modules fordirecting a service request to based on the indications of operationalstatus of the other modules.

According to a second aspect of the present invention, there is provideda method of managing service requests from a first module acting as aclient module, to a plurality of other modules acting as server modules,the first module comprising a client application and a controlintermediary, the method comprising:

-   -   an information-collating module receiving from each of the other        modules an indication of the operational status of each of the        other modules;    -   the control intermediary receiving from the        information-collating module an indication of the operational        status of each of the other modules;

the control intermediary receiving a request for a Web servicedescription from the client application, and selecting one of the othermodules to direct the request to based on the indications of operationalstatus of the other modules;

the control intermediary receiving the requested Web service descriptionand substituting an identifier of the control intermediary into thedescription before passing the description to the client application.

According to a third aspect of the present invention, there is provideda system comprising a first module acting as a client module and aplurality of other modules acting as server modules, in which the clientmodule is arranged to send service requests to the other modules, thesystem further comprising:

an information-collating module arranged to receive from each of theother modules an indication of the operational status of the othermodules; and

the client module comprising a control intermediary arranged to receivefrom the information-collating module an indication of the operationalstatus of each of the other modules, and further arranged to select oneof the other modules for directing a service request to based on theindications of operational status of the other modules.

According to a fourth aspect of the present invention, there is provideda system comprising a first module acting as a client module and aplurality of other modules acting as server modules, the first modulecomprising a client application and a control intermediary, in which theclient module is arranged to send service requests to the other modules,the system further comprising:

an information-collating module arranged to receive from each of theother modules an indication of the operational status of the othermodules;

the control intermediary arranged to receive from theinformation-collating module an indication of the operational status ofeach of the other modules;

the control intermediary further arranged to receive a request for a Webservice description from the client application, and to select one ofthe other modules for directing a service request to based on theindications of operational status of the other modules; and

the control intermediary arranged to receive the requested Web servicedescription and substitute an identifier of the control intermediaryinto the description before passing the description to the clientapplication.

Specific embodiments according to the invention will now be described,by way of example, with reference to the accompanying drawings, inwhich:

FIG. 1 shows a schematic of a system according to the invention;

FIG. 2 shows a the system of FIG. 1 in more detail; and

FIG. 3 shows a method of handling Web service requests within the systemof FIG. 1.

Referring to FIG. 1, there is shown a system according to an embodimentof the invention. The system comprises a plurality of Web serviceservers 32 on which are running various applications which provideservice capabilities which a software client 31 requires. The systemalso comprises Web service proxy 30, a client side component, which actsas an intermediary for messages passing between client 31 and Webservice servers 32. The system further comprises a plurality ofmonitoring servers 35 which monitor the operational status of the Webservice servers 32, and which also transmit this information uponrequest to the proxy 30. Additionallly, the system comprises a pluralityof WSDL servers 34 which provide upon request WSDL servicespecifications detailing the Web services available on the Web serviceservers 32. The client side components further include softwaredevelopment kit 29, and a configuration file 33 for use by the proxywhen communicating with the servers 34, 32, 35.

In operation, a service specification (WSDL) request is generated byclient 31, and routed via the proxy 30 to one of the WSDL servers 34.The response, the WSDL, is then transmitted back from the WSDL server 34via the proxy 30 to the client 31, where it is used to generate thenecessary service request messages for accessing the Web servicecapabilities provided by servers 32. These service request messagesalso, and successful responses, are also routed via the proxy 31.Essentially, the proxy 30 acts as a distribution point though which allrequests for WSDL and all service request messages are passed.

The proxy 30, upon receipt of a request (either a WSDL request or a Webservice request message) from the client 31 will select which server toforward the request to on the basis of the current operational status ofthe servers. For example, the proxy 30 will forward a WSDL request to anappropriate WSDL server which is available and lightly loaded. Uponsuccessfully retrieving the WSDL from the WSDL server 34, the proxy 30parses the WSDL, replacing the service name and port to point instead tothe address of the proxy 30, before passing it back to the client 31

When the client receives the WSDL it is able to use it to automaticallycreate the necessary helper classes or to hand build the necessary Webservice requests (SOAP messages) for utilising the Web service. TheseSOAP messages are then directed through the proxy 30, which againdecides which Web service server 32 to forward the request to. If noresponse is received from the selected Web service server by the proxy30, it will record that the selected Web service server 32 has failed,and send the request to an alternative Web service server 32. This stepwill be repeated as necessary until a successful response to the requestis received by the proxy 30, which it then forwards to the client 31. Inthis manner, the client 31 uses the proxy 30 transparently, and will becompletely unaware of any re-routing, load sharing and load balancingwhich is being carried out.

In order to decide where to route the messages, the proxy 30communicates with a plurality of Monitoring servers 35, whose detailsare stored in configuration file 33. The proxy 30 receives informationabout the status of WSDL servers 34 and Web service servers 32 from theMonitoring servers 35, via use of a SOAP based or HTTP GET-RESPONSEpolling mechanism to draw the information from the Monitoring servers35. Monitoring servers 35 provide load information, server availability,and lists of which WSDLs and service names are available on particularservers. This information may be supplemented by more detailed statusinformation on individual server load and status (eg server shuttingdown in five minutes, server out of service). In this manner the proxy30 frequently updates itself on the status and availability of theservers, allowing it to both balance the loading of the serversefficiently, and also to accurately select an appropriate alternativeserver to re-route messages to in the event of a particular serverfailing.

In addition, the proxy 30 monitors the performance of the Web serviceservers 32 and WSDL servers 34 itself through the speed of response torequests, thus receiving a good indication of network latency and serverperformance so as to provide the best performance to the client 31 byredirecting the requests as necessary. It is envisaged that server andclient side components might be geographically widely dispersed, such asfor example, locating the client side compents on the US East coast,with the proxy operating so as to pull the WSDL off a server located onthe US West coast, and then subsequently routing SOAP messages to aserver farm in the UK.

The system is now described in more detail with reference to FIG. 2 andthe flow chart of FIG. 3. In particular, the proxy 30 comprises pollerthread 36 and local data store 37. The proxy 30, when started, performsa status check on the servers and Web services by polling the Monitoringservers 35 under its jurisdiction using the poller thread 36.Configuration file 33, as well as providing details pointing to theMonitoring servers 35 also holds authentication details for connectingto the Monitoring servers. When poller thread 36 polls the Monitoringservers 35, security principles and credentials are supplied to allowaccess and also so that the Monitoring server can identify the proxy 30and provide customised information if necessary.

The information received by proxy 30 from each Monitoring server 35 mayinclude indications of loading of servers 32, 34, Web serviceavailability, lists of what WSDLs, service names are available onparticular servers, and also information on the other Monitoring servers35. The received information are written into the local data store 37 inthe form of service records, WSDL records and Monitoring server records,such as some examples included in Appendix A:

Proxy 30 further comprises a listener thread 38, WSDL router thread 39and SOAP router thread 40. When a WSDL request sent from client 31arrives at the proxy 30, it is recognised by the listener thread 38 andguided to the WSDL router 39. The WSDL router 39 takes the service nameURI (Uniform Resource Indicator) eg “webservice1” and performs a lookupon the local-data store 37 to find an appropriate WSDL server. If one isfound a URL is constructed by the WSDL router 39, and the requestforwarded to the selected WSDL server. If no response is received, localdata store 37 is updated, another WSDL server selected and the requestresent.

Only after all the WSDL servers have been tried are all the options areexhausted, and the client is notified through HTTP 401 error. The lackof success is recorded in the local data store 37 as a negative number,i.e. HTTP 404 becomes −404. In most cases, the WSDL will be retrievedsuccessfully by the WSDL router 39, and the response time and successare recorded in the local data store 37. The WSDL is then parsed and thename and service port changed so as to point to the address of the proxy30. The WSDL is passed back to the client 31.

The client can then use the WSDL to automatically create the necessaryhelper classes or to hand build the SOAP messages for utilising the Webservice. The SOAP messages are then sent to the proxy 30, where they arereceived by the listener thread 38 and guided to the SOAP router 40. TheSOAP router performs a lookup (step 10) on the local data store 37 usingthe service name URI (eg “webservice1”) to find an appropriate Webservice SOAP server 32 (steps 11 and 12) chosen, for example based onprevious success, performance and current load.

For example, the Web service server may be selected based on pre-definedselection criteria, such as:

load share—the load is shared across a set of servers based on the“round robin” principle

load balance—the load is sent to the least busy server

past performance—the load is given to the fastest responding server

failover performance—the load is routed to available servers, avoidingservers in shutting down mode

Once the Web service server 32 has been- chosen, the SOAP routerconstructs a URL and sends (step 13) the SOAP message to the appropriateserver 32. In the event that a response from the server is not received,SOAP router 40 updates (step 14) the local data store 37, for examplewith HTTP −404, and then repeats (step 15) the earlier process byperforming a further lookup to select an alternative Web service server(repeat of steps 10, 11 and 12), and then resends the message (repeat ofstep 13). This is repeated (step 15) until either a successful responseis received (step 16) or there are no further suitable servers to try(step 17). Once all the options are exhausted the client 31 is notified(step 18) through an HTTP 404 error or SOAP Fault. In most cases, aresponse to the SOAP message will be successfully received, and theresponse time, success of the request and response is stored (step 14)against the relevant entry in the local data store. The response is thenforwarded (step 19) to the client 31.

In order to maintain records regarding the status of servers 32, 34, andalso regarding other Monitoring servers 35, a Monitor server willrepeatedly poll the other servers, either in response to the externalpolling mechanism from the proxy 30 or alternatively to a server-sidemonitor thread 41. Service availaibility checks are performed by theMonitoring servers 35 by:

-   -   attempting to request a WSDL or pinging the WSDL servers    -   calling a test method on the Web services and evaluating the        response from the Web service servers    -   attempting to request monitoring information from other        Monitoring servers 35

The system further comprises a Deployment Manager 42 to assist inmanaging the server side platform. The Deployment Manager 42 comprises aplurality of database tables, including:

-   -   Service Deployment Descriptions Table 43 (associates the various        services with the actual Web servers which provide them)    -   WSDL Deployment Description Table 44 (associates the lists of        WSDLs with the actual WSDL servers which provide them)    -   IMSS Deployment Description Table (information relating to the        Monitoring Servers)

Conveniently, the Deployment Manager 42 further comprises a DeploymentManagement Function 46 which allows a service operator to update theentries of Web service applications, WSDL and IMSS descriptionsaccording to any modifications made to the services, etc which aredeployed on the servers. A web Interface provides a simple way for theoperator of the platform to administer the service.

In the specific embodiment described, proxy 30 is delivered as a sofwarepackage comprising Java classes that run on JDK 1.3 JVM and above, andsupports current standards WSDL 1.1 and SOAP 1.1. A standard SDK 29allows the application developer to program in any language but accessWeb services thorugh simple commands. In the embodiment, the JAX-RPC 0.9and Microsoft SOAP Toolkits provide this functionality. Configurationfile 33 holds authentication details for connecting to servers usingHTTP Basic Authentication for inclusion within the SOAP messages as WSSEsecurity credential.

The server side of the system is implemented using Web servers or J2EEcomponents, though .Net servers and IIS could be used. In theembodiment, the servers are running on a client driven basis in thesense that they only respond to the external polling mechanism fromeither the proxy 30 or alternatively from a server side monitor thread41.

Client side components, proxy 30, configuration file 33, standard SDK-29and client 31 may be considered to be a single client module 28,communicating with the variety of different server side components (WSDLservers 34, Monitoring servers 35 and Web service servers 32) over anysuitable network, which in the specific embodiment is the internet.However, the type of network is not essential to the invention, and itis understood that the servers may be either local or remote.

It is anticipated that various modifications to the invention may bemade. For example, whilst a client side configuration file 33 is alsoprovided, to point to the available Monitorng servers 35, this couldalternatively be replaced by a database or an API that could allowconfiguration.

APPENDIX A MONITORING SERVER REPORT EXAMPLES

This information can be encoded in HTML, XML and SOAP form the followingexample is encoded in HTML (comments shown as //) // Addresses ofmonitor (Integrity Management System Servers ) IMSS - this case JSPs butthe could be XML or SOAP IMSS/server1=http://www.erica.bt.co.uk/IMSS.jspIMSS/server2=http://www.erica3.bt.co.uk/IMSS.jspIMSS/server4=http://www.erica4.bt.co.uk/IMSS.jsp // URLs ofimplementations of servicesSERVICE/erica_service1/testService=http://www.erica3.bt.co.uk/erica_service1 testService/SERVICE/erica_service1/testService=http://www.erica1.bt.co.uk/erica_service1 testService/SERVICE/erica_service1/testService=http://www.erica5.bt.co.uk/erica_service1 testService/ // WSDL of these servicesWSDL/erica_service1/testService=http://www.erica1.bt.co.uk/erica_service1 testService/WSDL/erica_service1/testService.wsdl=http://www.erica5.bt.co.uk/erica_service1/testService.wsdlWSDL/erica_service1/testService.wsdl=http://www.erica3.bt.co.uk/erica_service1/testService.wsdl // Throttleback settings of thisservice THROTTLEBACK/erica_service1/testService=5000 // Load of thisservice 0 = no load 10 = fully loadedLOAD/http://www.erica1.bt.co.uk/erica_service1/testService/=10LOAD/http://www.erica3.bt.co.uk/erica_service1/testService/=5LOAD/http://www.erica5.bt.co.uk/erica_service1/testService/=0 // Laststatus check in response in millisecondsPERFORMANCE/http://www.erica1.bt.co.uk/erica_service1/testService/= 151PERFORMANCE/http://www.erica3.bt.co.uk/erica_service1/testService/= 204PERFORMANCE/http://www.erica5.bt.co.uk/erica_service1/testservice/= 97// Status of servers (hosts)SERVER_STATUS/http:www.erica1.bt.co.uk=ACTIVESERVER_STATUS/http:www.erica3.bt.co.uk=ACTIVESERVER_STATUS/http:www.erica5.bt.co.uk= SHUTTING_DOWN_5_MINUTESSERVER_STATUS/http:www.erica6.bt.co.uk=SHUTDOWN // Poll IMSS rate inseconds HEARTBEAT_POLL_PERIOD=15

Local Store—Services records Accessed Service URL Load (Unix ms)Response /erica_service1/testServicehttp://www.erica5.bt.co.uk/erica_service1/testService 5 002120120 70/erica_service1/testServicehttp://www.erica5.bt.co.uk/erica_service1/testService 0 002120120 120/erica_service1/testServicehttp://www.erica5.bt.co.uk/erica_service1/testService 10 000000000 0

Local Store—WSDL Records Accessed WSDL URL (Unix ms) Response/erica_service1/testService.wsdlhttp://www.erica5.bt.co.uk/erica_service1/testService.wsdl 002120120 70/erica_service1/testService.wsdlhttp://www.erica1.bt.co.uk/erica_service1/testService.wsdl 002120120−404 /erica_service1/testService.wsdlhttp://www.erica3.bt.co.uk/erica_service1/testService.wsdl 000000000 0

Local Store—Server Status Records Accessed Server URL (Unix ms) Responsehttp://www.erica1.bt.co.uk ACTIVE 002120120 70http://www.erica3.bt.co.uk ACTIVE 002120120 120http://www.erica5.bt.co.uk SHUTTING_DOWN_5_MINUTES 000000000 0http://www.erica6.bt.co.uk SHUTDOWN 0 0

Local Store—Monitoring Server Status Records Server Accessed (Unix ms)Response IMSS/server1=http://www.erica1.bt.co.uk/IMSS.jsp 002120120 70IMSS/server2=http://www.erica3.bt.co.uk/IMSS.jsp 002120120 120IMSS/server4=http://www.erica4.bt.co.uk/IMSS.jsp 000000000 0http://www.erica6.bt.co.uk 0 0

HTTP Responses also Catered for: Status-Code = “200”; OK “201”; Created“202”; Accepted “204”; No Content “301”; Moved Permanently “302”; MovedTemporarily “304”; Not Modified “400”; Bad Request “401”; Unauthorized“403”; Forbidden “404”; Not Found “500”; Internal Server Error “501”;Not Implemented “502”; Bad Gateway “503”; Service Unavailable

1. A method of managing service requests from a first module acting as aclient module, to a plurality of other modules acting as server modules,the method comprising: an information-collating module receiving fromeach of the other modules an indication of the operational status ofeach of the other modules; at the first module, a control intermediaryreceiving from the information- collating module an indication of theoperational status of each of the other modules; the controlintermediary selecting one of the other modules for directing a servicerequest to based on the indications of operational status of the othermodules.
 2. A method according to claim 1, in which the first modulecomprises a client application and the control intermediary, the methodcomprising the control intermediary receiving a request for a Webservice description from the client application, and selecting one ofthe other modules to direct the request to based on the indications ofoperational status of the other modules; the control intermediaryreceiving the requested Web service description and substituting anidentifier of the control intermediary into the description beforepassing the description to the client application.
 3. A method accordingto claim 1, further comprising, the control intermediary repeating thestep of selecting one of the other modules for directing a servicerequest to, so as to identify an alternative other module, in the eventthat the transmission of the service request to the selected modulefails.
 4. A method of managing service requests from a first moduleacting as a client module, to a plurality of other modules acting asserver modules, the first module comprising a client application and acontrol intermediary, the method comprising: an information-collatingmodule receiving from each of the other modules an indication of theoperational status of each of the other modules; the controlintermediary receiving from the information-collating module anindication of the operational status of each of the other modules; thecontrol intermediary receiving a request for a Web service descriptionfrom the client application, and selecting one of the other modules todirect the request to based on the indications of operational status ofthe other modules; the control intermediary receiving the requested Webservice description and substituting an identifier of the controlintermediary into the description before passing the description to theclient application.
 5. A method according to claim 4, furthercomprising, the control intermediary receiving a service request fromthe client application, and selecting one of the other modules to directthe request to based on the indications of the operational status of theother modules.
 6. A method according to claim 5, further comprising thecontrol intermediary repeating the step of selecting one of the othermodules for directing a service request to, so as to identify analternative other module, in the event that the transmission of theservice request to the selected module fails.
 7. A method according toclaim 1, in which the control intermediary selects the one of the othermodules on the basis of the loading of the modules.
 8. A methodaccording to claim 1, in which the control intermediary periodicallypolls the information-collating module to obtain the indications of theoperational status of the other modules.
 9. A system comprising a firstmodule acting as a client module and a plurality of other modules actingas server modules, in which the client module is arranged to sendservice requests to the other modules, the system further comprising: aninformation-collating module arranged to receive from each of the othermodules an indication of the operational status of the other modules;and the client module comprising a control intermediary arranged toreceive from the information-collating module an indication of theoperational status of each of the other modules, and further arranged toselect one of the other modules for directing a service request to basedon the indications of operational status of the other modules.
 10. Asystem according to claim 9, the first module further comprising aclient application, the control intermediary arranged to receive arequest for a Web service description from the client application, andarranged to select one of the other modules to direct the request tobased on the indications of operational status of the other modules; thecontrol intermediary arranged to receive the requested Web servicedescription and substitute an identifier of the control intermediaryinto the description before passing the description to the clientapplication.
 11. A system according to claim 9, the control intermediaryfurther arranged to repeat the step of selecting one of the othermodules for directing a service request to, so as to identify analternative other module, in the event that the transmission of theservice request to the selected module fails.
 12. A system comprising afirst module acting as a client module and a plurality of other modulesacting as server modules, the first module comprising a clientapplication and a control intermediary, in which the client module isarranged to send service requests to the other modules, the systemfurther comprising: an information-collating module arranged to receivefrom each of the other modules an indication of the operational statusof the other modules; the control intermediary arranged to receive fromthe information-collating module an indication of the operational statusof each of the other modules; the control intermediary further arrangedto receive a request for a Web service description from the clientapplication, and to select one of the other modules for directing aservice request to based on the indications of operational status of theother modules; and the control intermediary arranged to receive therequested Web service description and substitute an identifier of thecontrol intermediary into the description before passing the descriptionto the client application.
 13. A system according to claim 12, thecontrol intermediary further arranged to receive a service request fromthe client application, and to select one of the other modules to directthe request to based on the indications of the operational status of theother modules.
 14. A system according to claim 13, the controlintermediary further arranged to repeat the step of selecting one of theother modules for directing a service request to, so as to identify analternative other module, in the event that the transmission of theservice request to the selected module fails.
 15. A system according toclaim 9, in which the control intermediary is arranged to select the oneof the other modules on the basis of the loading of the modules.
 16. Asystem according to claim 9, in which the control intermediary isfurther arranged to periodically poll the information-collating moduleto obtain the indications of the operational status of the othermodules.
 17. A system according to claim 9, in which the other modulesare Web service servers.
 18. A storage medium carrying computer readablecode representing instructions for causing processors to perform themethod according to claim 1 when the instructions are executed by theprocessors.
 19. A computer program comprising instructions for causingprocessors to perform the method according to claim 1 when theinstructions are executed by the processors.
 20. A computer data signalembodied in a carrier wave and representing instructions for causingprocessors to perform the method according to claim 1 when theinstructions are executed by the processors.
 21. A storage mediumcarrying computer readable code representing instructions for causingprocessors to operate as the system according to claim 9 when theinstructions are executed by the processors.
 22. A computer programcomprising instructions for causing processors to operate as the systemaccording to claim 9 when the instructions are executed by theprocessors.
 23. A computer data signal embodied in a carrier wave andrepresenting instructions for causing processors to operate as thesystem according to claim 9 when the instructions are executed by theprocessors.